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REMARKS 

This is an appeal of the Final Rejection dated May 12, 2008 of Claims 1, 3, 5-13, and 
15-20. A Notice of Appeal from this Final Rejection was timely filed on August 12, 2008. 
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L REAL PARTY IN INTEREST 

The real party in interest in this appeal is the assignee, TANDBERG TELECOM AS. 

IL RELATED APPEALS AND INTERFERENCES 

Appellants' legal representatives and the assignee are aware of no appeals which will 
directly affect or be directly affected by or have any bearing on the Board's decision in this 
appeal. 

III. STATUS OF THE CLAIMS 

In the Official Action dated March 12, 2008, Claims 1, 5-6, 1 1-13, 16, and 20 were 
rejected under 35 U.S.C. § 103(a) as being unpatentable over Nataraian et al. (U.S. Patent No. 
6,505,244, hereinafter Nataraian) in view of Weisman et al. (U.S. Patent No. 7,171,475, 
hereinafter Wdsman); and Claims 3, 7-10, 15, and 17-19 were rejected under 35 U.S.C. 
§ 103(a) as unpatentable over Nataraian , Wiesmann , and fiuther in view of Evans (U.S. Patent 
No. 5,694,524). 

IV. STATUS OF THE AMENDMENTS 
Appellants' latest amendment was filed on February 7, 2008 and was entered. All 
previous amendments were entered. 

V. SUMMARY OF THE CLAIMED SUBJECT MATTER 
While video conferencing has grown in popularity as businesses prefer more personal 
communications, video networks have grown in complexity.^ Video calls require the 
interfacing of plural network devices manufactured by plural manufacturers and 

^ Specification, page 2, lines 1-10. 
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communication protocols/interfaces.^ It is not unusual to encounter technical difficulties in 
video conferences using three or more endpoints.^ Conventionally, video network 
administrators have relied primarily on personal experience and intuition when 
troubleshooting problems in video networks."* 

Non-limiting embodiments of the present invention provide new ways to improve 
video network reliability. For example, historical data of previous video conferences are 
stored in a call history table (e.g, Fig. 3). An analysis of the historical data provides results 
which more effectively guide administrators in configuring video network for specific video 
calls.^ Furthermore, the historical data can be analyzed to determine ways to improve the 
video call.^ The quality of a subsequent or new video conference can be improved by the 
analysis of the call history table. A new call may be identified by a record that includes 
known characteristics for the new call (i.e., from-subnet, from-endpoint, to-subnet, to- 
endpoint, whether an MCU will be required).^ The known attributes of the new call may be 
used to identify a call configuration with a high probability of success. 

Briefly recapitulating. Claim 1 is directed to a method for modeling video 
conferencing network reliability. The method includes obtaining historical data for multiple 
video conferences, and storing the historical data in a call history table (e.g., item 102 in 
Figure 3). The historical data includes video conferencing equipment vendor or model 
identification information (e.g., specification, page 7, line 30 - page 8, line 22; Figures 3-5). 
The method also includes executing a modeling algorithm (e.g., item 101 in Figure 6; 
specification, page 9, lines 1-7) that produces a model representing the historical data, which 
includes executing a decision tree algorithm (e.g., specification, page 4, lines 9-11), 

^ Specification, page 2, lines 11-13. 
^ Specification, page 2, lines 24-26. 

Specification, page 2, lines 27-28. 
^ Specification, page 4, lines 23-25. 
^ Specification, page 10, line 27 to page 1 1, line 10. 
^ Specification, page 1 1, lines 18-22. 
* Specification, page 11, lines 22-23. 
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analyzing the model to identify characteristics associated with undesirable outcomes for the 
video conferences (e.g., specification, page 9, line 16 - page 10, line 2), configuring a video 
teleconferencing network to avoid at least one of the identified characteristics associated with 
undesirable outcomes (e.g., specification, page 10, line 15 -~ page 11, line 6), and conducting 
a new video conference with the video conferencing network configured to avoid at least one 
of the identified characteristics associated with the undesirable outcomes (e.g., Fig. 2, and 
specification, page 1 1, lines 1 1-30). Independent Claims 1 1 and 20 are directed to a 
corresponding computer storage medium and data processing system. 

VI, GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 
The first issue is whether Natarajan or Weisman discloses or suggests Appellants' 
historical data including video conferencing equipment vendor or model identification 
information (e.g., specification, page 7, line 30 - page 8, line 22; Figures 3-5). 

The second issue is whether Nataraian discloses or suggests Appellants' obtaining 
historical data for multiple video conferences, and storing this multi-conference historical 
data in a call history table. 

The third issue is whether Nataraian discloses or suggests Appellants' steps of 
executing a modeling algorithm (e.g., item 101 in Figure 6; specification, page 9, lines 1-7) 
that produces a model representing the historical data, analyzing the model, configuring a 
video teleconferencing network based on the analysis, and conducting a new video 
conference call with the video conferencing network configured to avoid at least one of the 
identified characteristics associated with undesirable outcomes. 
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VII. ARGUMENT 

Nataraian describes a feedback-based adaptive network wherein at least a portion of 
the network elements report operating information relating to network conditions to a 
centralized data store.^ The information which is reported to the data store is analyzed by a 
policy engine which includes a plurality of application specific plug-in policies for analyzing 
selected information from the data store and for computing updated control information based 
upon the analysis of the information.^*^ The updated control information is fed back to 
selected network elements to thereby affect operation of the selected elements.^* 

Nataraian does not disclose or suggest Appellants' call history table or Appellants' 
steps of executing a modeling algorithm that produces a model representing the historical 
data, analyzing the model, configuring a video teleconferencing network based on the 
analysis, and conducting a new video conference call with the video conferencing network 
configured to avoid at least one of the identified characteristics associated with undesirable 
outcomes. 

A. Both Nataraian and Weisman do not disclose or suggest Appellants' h istorical 
data including conferencing equipment vendor or model identification 
information. 

As acknowledged in the Official Action,^^ Nataraian does not disclose or suggest 
Appellants' historical data including conferencing equipment vendor or model identification 
information. To cure this deficiency, the Official Action points to Weisman, column 5, 
lines 38-53. However, this passage of Weisman merely refers to a discussion of a registered 
device provider DLL. A registered device provider DLL is not "historical data including 
conferencing equipment vendor or model identification information." 
^ Nataraian. Abstract. 

''Id. 

Official Action, page 5, lines 19-20. 
Official Action, page 6, line 21 to page 7. 
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Weisman describes a peer network host. Device host API 102 enables software 
modvdes (the hosted devices 108-109 and bridges 1 10 for bridged devices 1 12) to publish 
themselves as peer networking-enabled devices. These software modules are referred to 
collectively as "hosted devices" in Weisman . The hosted devices 108-1 10 register 
themselves with the Device Host 100 by providing information about their properties. This 
is done so that the Device Host can respond to discovery, presentation, and control requests 
from other peer networking devices. 

The registration in Weisman facilitates peer networking and is not historical data for 
multiple video conferences that includes video conferencing equipment vendor or model 
identification information. 

B. Nataraian does not disclose or suggest Appellants' obtaining hist orical data for 
multiple video conferences, and storing this multi-conference h istorical data in a 
call history table. 

The Official Action mailed May 12, 2008 refers to Figure 15 ofNataraian for a 
disclosure of Appellants' storing this multi-conference historical data in a call history table. 
This figure shows an example of a flow diagram for a data store event handler reporting 
procedure 1500. Procedure 1500 may be implemented via the event handling entity 272 
residing at data store 252. One responsibility of event handler 272 is to continually monitor 
the data store for new or updated control information which has been generated by the 
network elements or by the policy engine 254. When event handler 272 detects the 
occurrence or availability of a new control parameter, it notifies the event server 270 which 



Weisman . col. 4, lines 1-4. 
Weisman , col. 4, lines 4-5. 
Weisman . col. 4, lines 27-29. 
Weisman, col. 5, lines 29-32. 

Official Action, mailed May 12, 2008, page 3, last line, to page 4, line 1. 
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distributes the event notification message onto the appropriate network element(s).^^ Thus, 
data store 252 stores data relative to events used by or relating to event handler 272. 
However, this event data is not Appellants' historical data for multiple video conferences. 
That is, the event data of Nataraian has no persistence from one process to another. Said 
differently, the event data of Nataraian pertains to a single video teleconference, not to 
multiple video teleconferences as required by Appellants' claims. 

To understand this point, it is first necessary to identify what constitutes event data in 
Nataraian . While the word "event" is used 247 times in Nataraian, the term 'event' is never 
explicitly defined. However, an implied definition may be derived from the following 
examples of events disclosed in Nataraian : 

• ...notification for specified events, such as, for example, the availability of 
updated control information at data store 252?^ 

• Yet another purpose of the event handler is to monitor specified network 

elements, and report the detection of specified events (e.g. detected errors) to 
event server 270. In an alternate embodiment, the event handler is statically pre- 
configured so that when it is initialized, it automatically monitors a specified 
network element for specific types of events and reports detected events to event 
server 270. For example, when an error is detected by network element 204A, the 
event handler 274A will report the error to event server 270 to be forwarded to 
other network and/or control elements (e.g. policy engine 254), which may be 
interested in this type of information.^^ 

• Event handler 272 continually monitors the data store for updated control 
information and other events .^^ 

• The policy engine may either repeatedly poll the data store for updated network 
data, or rely on an event service to be notified that a change in the network 

23 

conditions has occurred . 

• The application specific policy may be automatically loaded upon on initialization 
of the policy analysis procedure, or may be loaded subsequently upon the 
occurrence of an event, such as, for example, the exec ution of a specific user 
a pplication .^"^ 



Nataraian . column 25, lines 27-55. 
Nataraian , column 10, lines 21-25. 
Nataraian, column 10, lines 41-57. 
Nataraian , column 10, line 67 - column 11, line 1. 
Natarajan. column 13, line 66 - column 14, line 2. 
'^^ Nataraian. colunrn 15, lines 42-46. 
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• The event handler 274A may initially consult a local configuration file (not 

shown) in order to determine which events the network element is to register for at 
the event server 270.^^ 



However, none of these events are related to multiple video teleconferences as 
required by Appellants' claims. That is, there is no indication that an error of one process 
(e.g., conference) to be used in another process (e.g., conference). There also is no rationale 
for an error of one process (e.g., conference) to be used in another process (e.g., conference). 
Similarly, there is indication that any of the other examples of events described in Nataraian 
arising in a first process (e.g., conference) would be applicable to a second process (e.g., 
conference). 

The Official Action of May 12, 2008 also cites to column 7, lines 12-43 of Nataraian 
for a disclosure of Appellants' claimed storing of historical data of multiple conferences in a 
call history table. Appellants traverse this finding and note that the cited passage of 
Nataraian recites: 

"The feedback-based adaptive network of the present invention utilizes a 
technique wherein at least a portion of the network elements (e.g., 204 A, 
204B, 208A, 208B, etc.) report network information relating to network 
conditions to a centralized data storage entity (e.g., data store 252). The 
reported data corresponds to information relating to the current condition or 
status of each of the reporting network elements in the network . The 
information which is reported to the data store 252 is analyzed by a policy 
engine 254. The policy engine 254 includes a plurality of application specific 
plug-in policies for analyzing application specific information firom the data 
store and for computing updated control information based upon the analysis 
of the information . The updated control information may include any type of 
information, parameters, and/or actions which may be used to affect the 
operation of one or more network elements. The updated control information 
is then fed back to selected network elements to thereby affect operation of 
the selected elements and/or network. Typically, when the operation of a 
network element has been affected, its corresponding operating parameters 
and/or operating information will change. The changed operating parameters 
are then reported to the data store 252 and analyzed by the policy engine 254. 
The policy engine may then generate new or updated control information or 
parameters for affecting the operation of selected elements in the network. In 



Nataraian, column 19, lines 25-28. 
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this way, the network of FIG. 2 is configured to adapt to changing conditions 
in the network by providing a dynamic feedback mechanism. Using this 
dynamic feedback mechanism , selected network elements may be 
dynamically and automatically reconfigured to cause the performance of 
various aspects of the network to conform with desired performance criteria." 

Appellants first submit that the above-cited passage of Nataraian discloses nothing related to 
call history or a call history table. The only data apparently stored in this passage is "changed 
operating parameters are then reported to the data store 252." However, neither the recited 
changed operating parameters nor any other information (e.g., the control information and 
parameter information analyzed by the policy engine 254) is call history data, let alone call 
history data of multiple video conferences. 

First, as with the previous discussion of 'events', there is no indication that "current 
conditions" of equipment involved in one process (e.g., conference) are used in another 
process (e.g., conference). There also is no rationale for "current conditions" of equipment 
involved one process (e.g., conference) to be used in another process (e.g., conference). The 
process, events and models of Nataraian are directed exclusively to single video 
teleconferences, and not to management of multiple video teleconferences via use of 
historical data. 

Indeed, the only reference to a video teleconference in Nataraian is found relative to 
the example of Figures 16-18 ("Using the network illustrated in FIG. 16, various aspects of 
the present invention will now be described by way of example in which a video 
teleconference is established between userl (1602) and user2 (1620). The video 
teleconference example is described in greater detail with respect to FIGS. 17 and 18 of the 
drawings.").^^ A review of the entirety of column 29, line 36 - column 33, line 62 reveal that 
the events monitored relate to a single video teleconference, not to multiple video 
teleconferences as required by Appellants' independent claims. 

Nataraian, column 29, lines 53-58. 
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Nataraian does not disclose or suggest storing historical data for multiple video 
conferences in a call history table. 

C. Nataraian does not disclose or suggest Appellants' steps of executin g a modeling 
algorithm that produces a model representing the historical data, analyzing said 
model, and configuring a video teleconferencing network based on said analysis. 

Pages 14-15 of the Office Action refers to Fig. 17 of Nataraian when addressing the 

above-noted elements of Claim 1. The Office's interpretation of Fig. 17 of Nataraian is 

incorrect. 

Figure 17 of Nataraian shows a flow diagram of how the feedback-based network of 
Figure 16 adapts to changing conditions in the network as a video teleconference is initiated 
between user 1 and user 2. A video teleconference application between user 1 and user 2 is 
one example of a user application which may require additional bandwidth in order to 
provide a satisfactory level quality for using the application to service multiple users across 
the network. Thus, the video teleconference example may be abstracted to be applied to any 
user application requiring additional network resources to provide a satisfactory level of 
quality for the application to run over a network environment. When a video teleconference 
begins between users 1 and 2, the network may respond by initiating one or more bandwidth 
policies at the policy engine 1654 and may also respond by initiating one or more 

27 

policies/procedures at the monitor system 1662. 

At 1704 in Figure 17 of Nataraian the frame relay CIR policy is initiated at the policy 
engine 1654 if this policy has not already been initiated. While the frame relay CIR policy is 
being initiated by the policy engine at 1704, a CIR policy monitor procedure is concurrently 
initiated (1716) at monitor system 1662, if this procedure has not already been initiated. At 
1706, each of the links a, b, c, d of Figure 16 reports the number of packets dropped on that 

Nataraian . column 29, line 36 through column 30, line 66. 
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link to data storage 1652. The frame relay CIR policy at the policy engine 1654 uses this 
data to generate (1708) updated CIR parameter values for each of the respective links. The 
updated CIR parameter values generated by the policy engine are then written (1710) into the 
data store 1652. Once the appropriate network elements have been notified of changed 
network conditions, each of the network elements may retrieve a respective updated CIR 
parameter information from the data store 1652 and then update its configuration using the 
updated CIR parameter information. 

In the CIR policy monitor procedure of Figure 17, the quality monitor system 1662 
(FIG. 16) may concvirrently and continuously monitor the effectiveness of the frame relay 
CIR policy implemented by the policy engine. In the example of Figure 17, the effectiveness 
of the frame relay CIR policy is measured by analyzing the number of packets dropped at 
each of the respective links A, B, C, D, and comparing this data to predetermined criteria or 
guidelines. Thus, for example, at 1718, the reported number of packets dropped for links A, 
B, C, D are analyzed and compared to a predetermined threshold in order to evaluate the 
effectiveness of the frame relay CIR policy implemented by the policy engine. A 
determination is then made (1720) as to whether the frame relay CIR policy is effective in 
maintaining the number of dropped packets on each or any of the respective links below the 
predetermined threshold value. If it is determined that the current frame relay CIR policy is 
effective in maintaining the number of dropped packets on each of the respective links below 
a predetermined threshold, the quality monitor system 1662 may wait (1722) a specified time 
interval (e.g., 0-30 minutes) before re-evaluating the effectiveness of the current frame relay 
CIR policy by analyzing newly updated information relating to the number of packets 
dropped at each of the respective Imks. 



^' Nataraian. column 31, lines 33-57. 
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However, contrary to the Official Action, none of the data monitoring and analysis of 
these, or any other, passage of Natarajan relates to Appellants claimed executing a modeling 
algorithm that produces a model representing the historical data, analyzing said model, and 
configuring a video teleconferencing network based on said analysis. That is, for the 
reasons previously presented, Nataraian does not monitor or use Appellants' claimed 
historical data. Also, the monitored, stored and analyzed event data of Natarajan is not used 
for configuring a video teleconferencing network. Instead, the data is used to assess the 
viability of a current frame relay CIR policy. Nothing in Nataraian discusses configuring or 
reconfiguring a video teleconferencing network based on the event data, 

D. Nataraian does not disclose or suggest Appellants^ step of conducting a new video 
conference with the video conferencing network configured to avoid at least one of 
the identified characteristics associated with undesirable outcomes 

The Office Action relies on Figure 17 of Natarajan to describe the above-noted 
elements of Claim 1. However, Figure 17 of Natarajan does not describe or suggest 
"conducting a new video conference with the video conferencing network configured to 
avoid at least one of the identified characteristics associated with undesirable outcomes." 
Page 5 of the Office Action cites to elements 1720, 1724, 1726, and 1728 of Figure 17 of 
Nataraian when rejecting Claim 1. Element 1702 of Natarajan indicates that an initial video 
conference is initiated. However, elements 1720, 1724, 1726, and 1728 merely describe 
evaluating a current policy, and dynamically modifying the cvirrent policy. This is all done 
during the call initiated at block 1702. There is no "conducting a new video conference" that 
avoids the problems determined by elements 1720, 1724, 1726, and 1728 ofNatarajan. 

The Office Action also cites to col. 2, lines 15-43 ofNatarajan for this element of 
Claim 1 . However, this section of Natarajan merely describes retrieving information during a 
current video conference, and updating control information based on the retrieved 
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information for that current video conference. This is no disclosure or suggestion of 
conducting a new video conference that is configured to avoid the problem encoxmtered 
during the current video conference. 

VIII. CONCLUSION 

Appellants have considered Evans , and submit Evans does not cure the deficiencies of 
Nataraian and Weisman . As none of the cited prior art, individually or in combination, 
disclose or suggest all the elements of independent Claims 1, 11 and 20, Applicants submit 
the inventions defined by Claims 1, 1 1 and 20, and all claims depending therefrom, are not 
rendered obvious by the asserted references for at least the reasons stated above.^^ Thus, 
Appellants request that the rejections applied under 35 U.S.C. §103(a) to Claims 1, 1 1 and 20 
be reversed for the above-noted reasons. 



Respectfully submitted. 
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IX, CLAIMS APPENDIX 

Claim 1 (Rejected): A method for modeling video conferencing network reliability, 

the method comprising: 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data including video 
conferencing equipment vendor or model identification information; 

executing a modeling algorithm that produces a model representing the historical data, 
which includes executing a decision tree algorithm; 

analyzing the model to identify characteristics associated with undesirable outcomes 
for the video conferences; 

configuring a video conferencing network to avoid at least one of the identified 
characteristics associated with undesirable outcomes; and 

conducting a new video conference with the video conferencing network configured 
to avoid at least one of the identified characteristics associated with xmdesirable outcomes. 

Claim 2 (Canceled). 

Claim 3 (Rejected): The method of Claim 1, wherein the operation of executing a 
decision tree algorithm comprises executing an IDS -based algorithm. 

Claim 4 (Canceled). 

Claim 5 (Rejected): The method of Claim 1, fiirther comprising: 
updating the historical data to create new historical data that includes values 
representing characteristics of the new video conference; 
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executing the modeling algorithm to produce a new model representing the new 

historical data; 

analyzing the new model to produce a result; and 

reconfiguring the video conferencing network according to the result. 

Claim 6 (Rejected): The method of Claim 1, further comprising: 
evaluating the model to determine whether the model provides a desired level of 
efficacy; and 

in response to determining that the model does not provide a desired level of efficacy, 
using a different modeling algorithm to produce a different model. 

Claim 7 (Rejected): The method of Claim 1, wherein: 
the method further comprises bviilding a training set from the historical data; 
the operation of executing the modeling algorithm comprises applying the modeling 
algorithm to the training set; and 

the operation of analyzing the model comprises: 
deriving a rule set from the model; and 

analyzing the rule set to identify the characteristics associated with undesirable 
outcomes for the video conferences. 

Claim 8 (Rejected): The method of Claim 7, wherein: 

the historical data includes attribute values for attributes of each video conference and 
an outcome value representing an outcome for each video conference; and 

the operation of applying the modeling algorithm to the training set comprises: 
using the outcome values as categorical attributes for the modeling algorithm; and 
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using the attribute values as non-categorical attributes for the modeling algorithm. 
Claim 9 (Rejected): The method of Claim 7, wherein: 

the operation of obtaining historical data for multiple video conferences comprises 
obtaining a first endpoint identifier, a first endpoint vendor, a second endpoint identifier, a 
second endpoint vendor, and an outcome value for the multiple video conferences; 

the operation of building a training set comprises including the first endpoint 
identifier, the first endpoint vendor, the second endpoint identifier, the second endpoint 
vendor, and the outcome value for the multiple video conferences in the training set; and 

the operation of executing the modeling algorithm comprises using the first endpoint 
identifier, the first endpoint vendor, the second endpoint identifier, the second endpoint 
vendor, and the outcome value for the multiple video conferences to produce the model. 

Claim 10 (Rejected): The method of Claim 7, wherein: 

the training set includes values representing a first set of attributes; and 

the method further comprises: 

evaluating the model to determine whether the model provides a desired level of 
efficacy; 

in response to determining that the model does not provide a desired level of efficacy, 
building a different training set that includes a different set of attributes; and 

applying the modeling algorithm to the different training set to produce a different 

model. 
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Claim 1 1 (Rejected): A computer storage medium storing instructions, which when 

executed by a computing device, causes the computing device to perform functions 

comprising: 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data including vendor 
or model identification information; and 

executing a modeling algorithm that produces a model representing the historical data, 
which includes executing a decision tree algorithm; 

analyzing the model to identify characteristics £issociated with imdesirable outcomes 
for the video conferences; 

configuring a video conferencing network to avoid at least one of the identified 
characteristics associated with undesirable outcomes; and 

conducting a new video conference with the video conferencing network configured 
to avoid at least one of the identified characteristics associated with vindesirable outcomes. 

Claim 12 (Rejected): The computer storage medium of Claim 11, wherein the 
functions further comprise: 

outputting results that reveal at least one of the opportunities for improving reliability 
of the video conferencing network, such that a user can reconfigure the video conferencing 
network, based on the results, to improve reliability of the video conferencing network. 

Claim 13 (Rejected): The computer storage medium of Claim 11, wherein the 
fimctions fiirther comprise: 

analyzing the model to identify the one or more opportunities for improving reliability 
of the video conferencing network; and 
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automatically reconfiguring the video conferencing network, based on the identified 

opportunities, to improve reliability of the video conferencing network. 

Claim 14 (Canceled). 

Claim 15 (Rejected): The computer storage medium of Claim 11, wherein: 
the executing the decision tree algorithm comprises executing an ID3 -based 
algorithm. 

Claim 16 (Rejected): The computer storage medium of Claim 11, wherein the 
functions further comprise: 

updating the historical data to create new historical data that includes values 
representing characteristics of a new video conference; 

executing the modeling algorithm to produce a new model representing the new 
historical data; 

analyzing the new model to produce a result; and 

reconfiguring the video conferencing network according to the result to improve 
reliability of the video conferencing network. 

Claim 17 (Rejected): The computer storage medium of Claim 11, wherein the 
functions further comprise: 

building a training set from the historical data; 

executing the modeling algorithm by applying the modeling algorithm to the training 
set; and 
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deriving a rule set from the model, such that the one or more opportunities for 

improving reliability of a video conferencing network can be identified with the rule set. 

Claim 18 (Rejected): The computer storage medium of Claim 17, wherein: 
the historical data includes attribute values for attributes of each video conference and 
an outcome value representing an outcome for each video conference; 

the modeling algorithm uses the outcome values as categorical attributes; and 
the modeling algorithm uses the attribute values as non-categorical attributes. 

Claim 19 (Rejected): The computer storage medium of Claim 17, wherein the 
functions further comprise: 

obtaining a first endpoint identifier, a first endpoint vendor, a second endpoint 
identifier, a second endpoint vendor, and an outcome value for the multiple video 
conferences; 

storing in the training set the first endpoint identifier, the first endpoint vendor, the 
second endpoint identifier, the second endpoint vendor, and the outcome value for the 
multiple video conferences; and 

using, by the modeling algorithm, the first endpoint identifier, the first endpoint 
vendor, the second endpoint identifier, the second endpoint vendor, and the outcome value 
for the multiple video conferences to produce the model. 

Claim 20 (Rejected); A data processing system for modeling video conferencing 
network reliability, the data processing system comprising: 
one or more processing units; and 
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a computer storage medium storing instructions, which when executed by the one or 

more processing units, causes the one or more processing units to perform functions 

including 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data including vendor 
or model identification information; and 

executing a modeling algorithm that produces a model representing the historical data, 
which includes executing a decision tree algorithm; 

analyzing the model to identify characteristics associated with undesirable outcomes 
for the video conferences; 

configuring a video conferencing network to avoid at leeist one of the identified 
characteristics associated with undesirable outcomes; and 

conducting a new video conference with the video conferencing network configured 
to avoid at least one of the identified characteristics associated with undesirable outcomes. 



21 



Application No. 10/045,303 

Reply to Office Action of May 12, 2008 



X, EVIDENCE APPENDIX 



None. 
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XI. RELATED PROCEEDINGS APPENDIX 



None. 
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